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Abstract — In this paper, we propose an architecture for 
Network of Information mobile node (Netinf MN). It bears 
characteristics and features of basic Netinf node architecture 
with features introduced in the LISP MN architecture. We also 
introduce a virtual node layer for mobility management in the 
Network of Information. Therefore, by adopting this architecture 
no major changes in the contemporary network topologies is 
required. Thus, making our approach more practical. 

I. Introduction 

4WARD |l] is the proposed architecture and design for the 
Future Internet. The Network of information (Netinf) is one 
of the components of the 4 WARD project. The cornerstone 
of this architecture is that the information takes the prime 
position superseding the node-centric approach of the current 
internet. The genesis of Netinf was influenced by existing 
major technologies and beyond. The features which Netinf 
exhibits are the melange of existing and innovative solutions. 

Mobility is one of the scenarios considered in Netinf. 
Late Locator Construction (LLC) 13 is a proposal to handle 
mobility and multihoming issues in Netinf. It implements the 
locator/identifier separation idea. Whenever there is a mobility 
or rehoming event, there is no interruption in the ongoing 
TCP session between nodes. The notion behind the LLC is 
to use a Global Locator (GL) for routing between the Core 
Network (CN) and the Edge Networks (ENs). IPv4/IPv6 can 
be considered as the CN and nodes, mobile or stationary, 
forming a topology at the edge of CN, can be considered 
as ENs. GL is built inside the Locator Construction System 
(LCS) which is embedded inside the core network. Each 
Edge Network (EN) and the host attached to these ENs have 
Attachment Registers (AR) within the LCS. Each AR has IDs 
of itself and of its neighbors. The overall goal of LLC is 
to minimize the update signaling to the Locator Construction 
System (LCS) to update the GL to deal with the scalability 
problem within the core network. It has also been proposed 
that the core network scales well as core and edge networks 
are responsible for their own routing 0. 

Location Identifier Separation Protocol (LISP) Q is a 
network based approach for locator/identifier separation. It 
focuses on limiting the size of routing tables and improving 
scalability and routing system. LISP Mobile Node (MN) Q] 
is an extention to the classic LISP for mobile nodes. It has 
multiple design goals including a wide range of commu- 
nication possibilities in different mobility cases along with 
multihoming in MN, as well as allowing MN to act as a 



server. The LISP MN architecture has some LISP features 
together with additional characteristics to support mobility and 
rehoming events. What has been envisaged here for Netinf is 
to provide seamless connectivity between the mobile nodes 
even if there is a simultaneous roaming. Embedding LISP MN 
features in Netinf MN can then improve mobility management 
in LLC for the Netinf architecture. 

II. Mobility Management in NetInf 

Although LLC is a good proposal, it has however some 
discrapencies in terms of properly addressing both scalability 
and mobility issues. LISP MN inherits classic LISP features 
but lacks complete compatibility to work with LLC. Our 
proposal consists in a new approach to deal with these issues. 
The prime goal is the mobility management in Netinf. A 
Netinf MN should bear charactersitics and features of classic 
Netinf node architecture together with features introduced by 
the LISP MN architecture. The design goal of such a node is 
to deal with mobility in a highly dynamic environment. 

A. Netinf MN Architecture 

Fig. 1 presents a high-level overview of the Netinf MN 
architecture. At the bottom both physical and network layers 
provide services to the transport layer placed above. Within 
the transport layer is located the transport control engine 
(TCE). In Netinf, TCE is responsible for the coordination of 
protocols used for accessing Netinf objects. In this design, 
both Inner Locator Construction Tunnel Router (ILCTR) and 
Outer Locator Construction Tunnel Router (OLCTR) include 
their functionalities in TCE. The goal of these two routers 
is to work under the conditions when non-Netlnf sites are 
communicating. The working of these routers will be exten- 
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Fig. 1. Netinf Mobile Node Architecture. 

sively explained in the future work. The virtual node layer 



within the TCE is another feature introduced for the mobility 
management of information. At the top, the API provides 
services to users. This API gets services from the transport 
layer below. It should be noted that Netlnf and the nodes 
are interdependent on each other. Nodes are dependent on 
Netlnf for the network management, while Netlnf depends 
on nodes in scenarios where it has to manage and propagate 
the resources inside the network. 

B. Mobility Scenarios 

In order to understand the basic functionalities of our 
proposed architecture, consider two mobility scenarios. In Fig. 
2, MN1 roams into a new edge network EN3 during the on- 
going session with a stationary node MN2 in edge network 
EN2. MN1 first contacts local server LS in EN3 to register its 
new ID allocated by the DHCP. It also queries the local cache 
mechanism to find any trace of MN2 activities in EN3. If it 
is successful in finding one, it can use that cached locator and 
resume its session. Otherwise, it contacts the core network. 

Fig. 3 presents a simultaneous rehoming event. Two mobile 
nodes MN1 and MN2 are communicating in their respective 
edge networks EN1 and EN2. A mobility event occurs when 
both mobile nodes move to a new edge network EN3 at 
the same time. In this case, it would be more efficient if 
mobile nodes MN1 and MN2 could access a local server in 
EN3 and register their IDs to continue their session, instead 
of connecting to the core network. As IDs are global and 
unique, no further name resoluton is then required. However, 
a lookup request must be sent to the local server when both 
nodes are registered and each node should set TTL. If nodes 
relocate each other before their TTL expires, the session is re- 
established (in case of interruption) or continued. Otherwise, 
both should contact the core network. 

III. Mobility Management of Information in 
NetInf through Virtual Node Coordination 

The main problems faced in the network because of mobility 
are: the unpredictable motion of nodes and unpredictable 
availability of nodes i.e. nodes are continuously joining and 
leaving the network. Since information takes the centric po- 
sition within the network, the mobility management of the 
information becomes a major concern. One solution for the 
management of information mobility is the use of virtual 
mobile nodes. These virtual nodes can be thought of as a 
program running on real nodes. Whenever there is a mobility 
or rehoming event, the node which departs from the local 
network handovers its connectivity to one of the virtual nodes 
so that the connectivity of the ongoing session is carried away 
smoothly. This is made possible in our proposed Netlnf MN 
architecture by the introduction of a new layer, the Virtual 
Node layer that provides virtual mobile node services in 
coordination with the real node. All mobile nodes can act as 
temporary virtual mobile node and can provide services to the 
local mobile nodes. 

For example, in Fig. 2 EN1 hosts two nodes namely MN1 
and MN3. These two nodes have the ability to support virtual 



mobile node features introduced in their respective layered 
architecture. Lets assume that MN1 is in session with MN2 
in EN2. When MN1 moves from EN1 to EN3, it initiates 
the algorithm to make use of the embedded virtual layer. 
It contacts MN3 in EN1 and establishes a local connection 
by informing about its new destination (EN3). MN3 is now 
acting as a virtual MN1 and is communicating with MN2. This 
continues until MN1 reaches EN3. When this happens, it gets 
all the updates from MN3 and reconnects to MN2 again. 
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Fig. 2. Single Mobile Node Roaming. 




Fig. 3. Simultaneous Mobile Nodes Roaming towards same Edge Network. 

IV. Conclusion and Future Work 

There are still some open issues to be addressed for the 
proposed architecture for mobile entities in Netlnf. So far, 
the work is on the midway. ILCTR and OLCTR services 
are yet to be finalised. Besides providing services for non- 
Netlnf sites, they can also work as storage spaces in edge 
networks in case of disconnection from the core network. 
Different parameters have to be considered to evaluate the 
proposal. As ILCTR encapsulates packets before sending them 
to non-Netlnf sites, how could the Maximum Transmission 
Unit (MTU) be maximized. A new efficient protocol shall be 
proposed to deal with the mobility cases presented above. At 
present, we are in the process of evaluating our architecture 
through extensive simulations and real mobility traces. Finally, 
we plan to address the multihoming issue along with the 
security issue during mobility. 
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